Why Is It So Hard to Define Software Architecture?

In recent years, software engineering researchers have elevated the study of software architecture to the level of a major area of study. A review of the published literature however, shows quite clearly that a unified view of software architecture has not been forth-coming. This paper contends that the existence of a "software architecture level of design" is based on the implicit assumption that the software development process is analogous to those "construction" disciplines in which the completed artefacts or systems exhibit a unique representational abstraction, fixed during the early stages of design, which we describe as "the architecture". We argue that our problems in obtaining an acceptable definition of software architecture are due to the assumption that software systems have an analogous, unique design abstraction, determinable at the early stages of the design. To determine the validity of this analogy, we contrast the nature and use of architecture in the traditional building process with software development to identify the differences, rather than the similarities that exist. These differences are explained using a theory of the software development process which highlights why these differences arise and, subsequently, why there has been trouble in developing a communitywide understanding of software architecture. Our conclusion is that due to the fundamental nature of the systems we construct, attempts to depict the large-scale structure of the system, in an analogous manner traditional building disciplines, results in many different architectures. These are fundamentally different representations and not merely different views of a single whole. Moreover, each of these is equally qualified to be labelled as the system architecture with respect to the general notion of what architecture is. 1 The Problem with the Definition of Software Architecture. Software developers have been discussing the "architecture" of their systems since the late 60's (see Dijkstra [1] and Spooner [2]) however, it was Shaw's 1989 paper, "Larger Scale Systems Require Higher Level Abstractions" [3], and Perry and Wolf's subsequent paper dealing with the foundations of the new research area [4], which triggered the growth in the field we call "software architecture". Despite the volume of research since those papers were published, it is suprising that the software development community has failed to agree on exactly what we mean by the "software architecture level of design". Even the most popularly cited definition, provided by Garlan and Shaw [5], is not universally agreed upon. Descriptions of system architecture range from conceptual models of design to source code organisation and touch on more abstract notions such as frameworks, patterns, and styles [6]. These multiple definitions make it hard to compare and contrast different ideas in the field because they are based on slightly different notions of what software architecture should be and the purposes that it should serve. Consequently, architectural representations of implemented systems depict different concepts depending on which definition is used or the architectural biases which predominate. Clements, in his overview of the field [7], suggested five reasons why the community has failed to reach on a consensus on what exactly is needed by software architecture. 1. Advocates bring their own methodological biases with them. While most definitions of the term agree at the core, they differ seriously at the fringes. Those differences are attributable to the motivation each researcher has for examining the structural issues in the first place. 2. The study is following practice, not leading it. Research still involves observing the design principles and actions used whilst developing real systems and abstracting the commonalities. 3. The field is still quite new. 4. The foundations have been imprecise. The field contains a remarkable number of undefined and ambiguous terms. In addition to the textual terms, diagrammatic representations of architectural structures also suffer from ambiguity in interpretation. 5. The term is over-utilised and its meaning as it relates to software engineering is becoming diluted. We assert that the issues raised by Clements are manifestations of a deeper reason preventing us from achieving convergence. Our detailed study suggests that much of the current research in software architecture appears to be based on the assumption that the process of software development is analogous to that of other disciplines which produce built systems, yet this assumption is rarely justified or even questioned.. As a consequence, the research community appears to be subscribe to the following implicit syllogism: "Traditional engineering disciplines design and build systems which exhibit a level of design abstraction known as the system architecture. Software developers build systems and can identify high level design abstractions. Therefore software systems have a system architecture". This paper examines that validity of that implicit analogy to determine why it is so hard to develop a community-wide agreement on what we mean by the software architecture level of design. To achieve this end we examine traditional building architecture and identify aspects of the fundamental nature of the systems they build and the materials used to build them. This is then contrasted with the discipline of software development to identify the differences between the fields. Finally these differences are used to determine the validity of the syllogism presented above. Comparisons between software development and traditional engineering disciplines occur in many aspects of software engineering research, however, whilst most papers attempt to highlight similarities between the disciplines to validate the analogy, we attempt to highlight the differences and then determine whether or not the analogies remain valid. We conclude that, due to the differences in the fundamental nature of the systems we build, and the materials we use to build them, software development does not have a unique architectural level of design. In fact, there exists three activities in the software development process in which high level representations are used and these activities all attract the term 'architecture'. They are: 1. The development of the conceptual model which defines the developers solution to the problem. 2. The arrangement of the static source code into the module and interconnection constructs provided by the programming language and operating environment. 3. The abstractions which depicts the systems conceptual operation and allows the developer to determine how well the implemented source code realises the solution depicted in the conceptual model. These are not multiple views of the one architecture they are three independent representations, all of which can rightfully be labelled with the term 'architecture'. 2. Comparison of Traditional systems and